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1.0 INTRODUCTION 
1. 1 Identification 

Evaluation of the Data Catalogue system was performed 
in response to lob order 85-617, covering work activities on 
the Data Integration Planning project. This work was 
performed in support of the Data Systems Development Branch 
(FD6) of the Institutional Data Systems Division (IDSD) at 
the National Aeronautics and Space Administra tion/L yndon B. 
Johnson Space Center (NASA/JSC) . 

1.2 Background 

Tools are needed to assist in evaluating the 
desirability and feasibility of integrating data files and 
data bases for several financial and administrative 
applications, such as the integration of the Basic 
Accounting System through the development of the Interactive 
Financial Management System (IFMS) . Data dictionary/ 
directory (DD/D) systems were recognized as capable of 
providing assistance. DD/D systems night also help minimize 
maintenance costs for existing applications, thus improving 
the effectiveness of data files maintained by the Branch in 
support of user organizations. The Data Catalogue system 
was selected by the Data Systems Development Branch for the 
evaluation of general data dictionary capabilities. 

The Data Catalogue system is a proprietary software 
package marketed by the Synergetics Corporation, Burlington, 
Massachusetts. Originally developed for the IBM 360/370, 
the system has been modified to run under EXEC 8 on the 
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(JNIVAC 1100 series. By arrangement with Synergetics, the 
Data Systems Development Branch was authorized to test the 
Data Catalogue system at JSC for a 30-day trial period. 
Initially scheduled to begin in August 1974, the trial 
period actually began January 9, 1975. However, all report 
generation capabilities of the system were available prior 
to the start of the 30-day period;, these and other 
capabilities were made available for testing a few at a 
time, beginning October 31, 1974. 

In summary, this project has the purpose of determining 
to what extent a DD/D system can assist the Data Systems 
Development Branch and IDSD in achieving optimum benefits 
from its substantial existinq and planned investments in 
computer data files. 


1.3 Evaluation Approach 

Of the commercially available data dictionary systems, 
only the Data Catalogue system is currently operational on 
the ONIVAC 1100, EXEC 8 system (ref. 1). Therefore, the 
Data Catalogue system must be evaluated in terms of whether 
it can satisfy specific needs, rather than in comparison to 
the performance of competitive products. This document 
establishes several potential DD/D system applications in 
support of the Data Systems Development Branch and discusses 
the performance of the Data Catalogue system in satisfying 
the specific needs of the Branch. 

Input data for the evaluation is based on COBOL source 
code for the Financial and Contractual Status (FACS) system. 
FACS was selected for this purpose because its data is 
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representative of the data used in financial and 
administrative applications, it is veil-documented, and the 
capability to describe the data to a DD/D system was still 
available to the Data Systems Development Branch. 

Data for IFHS was also converted to Data Catalogue 
format and is included in the reports which have been 
produced. This data, however, represents only the contents 
of various IFHS transactions and reports, neither of which 
can be identified as such to the Data Catalogue system. To 
avoid confusion, this evaluation does not reference the IFMS 
data because it is less useful than the FACS data. 


1-3 



2.0 POTENTIAL OSES OF A DATA DICTIONARY SYSTEH 

The potential uses of a DD/D system have been 
documented in several technical papers and reports (see refs 
2 , 3, and 4) . The distinction between dictionary functions 
and directory functions is described by Ohrowczik (ref 2) in 
terms of "management use mode" and "computer use mode," and 
in the November 1974 EDP Analyzer (ref 4) in terms of 
"source definitions" and "object definitions." Briefly, 
dictionary functions involve the storage, processing, and 
reporting of information about data to users of that 
information; directory functions involve the availability of 
information about data at the time of loading and executing 
programs which use the data. 

Throughout the remainder of this document ,. the Data 
Catalogue system will be referred to as having only data 
dictionary capabilities. The system does not perform any of 
the functions required of a data directory, which are 
discussed in greater detail in section 5.2. Data dictionary 
uses are categorized in this evaluation according to (1) the 
assistance they provide to the data control function of 
installation management and to the program development 
function and (2) the capabilities needed to provide that 

<r 

assista nee. 

2.1 Data Control Assistance 

* 

To provide useful results to users, installation 
management must exercise some degree of control, either 
centralized or decentralized, over its data resources. 
Increased emphasis on integrated data bases, which are 
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available to several applications, increases the degree of 
control needed for data resources. Accurate, current 
information about data base contents and structure should be 
readily available to management. Additional information 
would be needed to analyze the effect of restructuring or 
modifying a data base. Information required to support 
these functions includes the following: 

• Data description for analysis and standards control. 

- Descriptive text for each element or collection 
of elements 

- Source responsibility, defining the organization 
responsible for data and how the data originates 
Format 

Statistical data, such as volume and frequency, 
which would be useful for redundancy analysis or 
for performance analysis 
Cross reference data, such as 

(a) Data items used by a specific program 

(b) Programs in which a data item is used 

(c) Data names assigned in a specific program 

(d) Programs in which a ^data name is used 

• Security level reports by file,, record, and element. 

• Data structure. 

y 

Logical - relationships among data elements 
(dependency or derivability) and among records 
(parent-child or owner- member) 

Physical - storage structure for data elements, 
groups, records, and files 
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2.2 Program Development Assistance 


Ose of a DD/D in support of the programming function 
may be of many different types. Only those of an 
informational nature or requiring only limited computational 
support are discussed in this document. Uses requiring 
directory capabilities are not discussed (see section 5.2). 
Information required to support applications programming 
functions include the following: 

• Data description. 

- Descriptive text for data elements, group items, 
records, and files 

- Data formats ' 

Definition of the contents of records, files, 
reports, and transactions 

- Edits required for specific elements 

- Conversion and compaction techniques 

- Da ta na me s 

• Source code generation. 

• Test data assistance. 

- Value ranges and dependencies 
Data generation 


x 
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3.0 EVALUATION OF THE DATA CATALOGUE SYSTEM 


Data Catalogue system capabilities will only partially 
support the needs discussed in the preceding sections. A 
summary of the degree of support provided is shown in table 
I. Areas of potential use are discussed in the succeeding 
paragraphs. 


3.1 Data Description 

Overall, data description capabilities of the Data 
Catalogue system are very good and reasonably easy to use, 
assuming that the source data is available. Some exceptions 
to this statement are noted later in this section. 

Descriptive data maintained by the system provides 
support best for functions related to documentation and to 
standards control. The examples shown in the appendix 
illustrate the descriptive data in the Catalogue report, the 
Index reports,, and the Cross-Reference reports. Data in the 
Catalogue report, for example, will provide a significant 
portion of the basic data included in the definition of 
application system reguirements. Much of the data in the 
FACS System Requirements document (ref 5) is now in Data 
Catalogue files. 

Central control is not now exercised over the 
assignment of data names in applications programs 
implemented for the Data Systems Development Branch. As a 
result, a multiplicity of names are generally assigned to 
each element within each system. (Fourteen data names in 
FACS are used to refer to the element Fund Source.) 



TABLE I.- SUMMARY OF DATA CATALOGUE CAPABILITIES 


Item 

Data description 
Text 

Cycle, frequency 
Volume data (records) 

Format 

Source 

Data structure-logical 

Owner-member relationships 
Element-dependency, derivability 
Data structure - physical 
Elementary, group items 
Records 

Files, data bases 

Reports 

Transactions: 

System 

Security level 
Elementary items 
Records, files 
Reports 

Programming (assistance) aids 
Source code generation - COBOL 
Edit description 
Test data assistance 
Value ranges 
Dependencies 
Generation 


Degree of 
support 

Good 

Fair 

None 

Good 

Good 

None 

None 

Good 

Good 

Good 

Fair 

Fair 

None 

Fair 

None 

None 

Good 

None 

Good 

Fair 

None 
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Standards in this area could provide better management of 
the naming function; fever names, carefully chosen, could 
simplify program maintenance tasks and possibly reduce 
computer resources required for compilation. Op to 90 data 
names may be assigned to each item in the Data Catalogue. 

Data description needed for performance analysis or 
redundancy analysis, such as volume of records of a given 
definition in a data base, is not specifically provided by 
the Data catalogue system. Cycle and frequency data are 
included only for elementary and qroup items and are 
confusinq to use. 

The appendix includes several examples of the various 
reports. Sections A.1, A. 2, and A. 3 describe the Catalogue 
report for elementary items, group items, and records, 
respectively. Section A. 4 shows some of the indexes 
produced by the system, and section A. 5 provides an example 
of a Cross-Reference report; these reports are used to index 
and cross-reference data in the Catalogue report. The 
capability of being more selective in generating these 
reports would be a valuable feature. 

Most of the descriptive data may be omitted at the 
option of the installation, through appropriate designation 
of "Installation Standards.' 1 The intended use of the 
Installation Standards capability, namely, to detect and 
report omission of data designated as mandatory or semi- 
mandatory, could help assure that data entries for the 
dictionary are complete. 
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Data description capabilities are probably the 
strongest feature of the system. Nevertheless, the guality 
of the descriptive reports should be improved. In the 
Catalogue report, for example, abbreviations should be 
avoided wherever practical, codes should be interpreted, and 
spacing should be handled more carefully. Consideration 
should be given to listing, at most, one data item 

j 

(elementary, group, or record) on a page, with the added 
capability of listing only a single or a few catalogue 
entries following an update. 

Problems with other reports indicate that the system 
may not yet be fully debugged. For example, entries in some 
of the index reports (Index by Program, Index by Source 
Department) are not sorted alphabetically. in the Structure 
report listing for an elementary item, the first two lines 
are truncated erroneously. 

3.2 Data Structure - Logical 

Logical data structures considered here are the parent- 
child or owner-member relationships among the records in a 
data base, and data element dependencies and derivability . 

No real support is provided in either of these categories by 
the Data Catalogue system. Logical data structure 
relationships are not identified in the system; logical 
record structures are supported only to the extent that they 
are the same as physical record structures. 

The 1971 CODASYL Data Base Task Group (DBTG) report 
(ref 6) defines data base tree structures and networks using 
the parent-child relationship among sets of data or records. 
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The capability to describe these relationships would be a 
valuable data dictionary feature. The description of these 
relationships would require designating all parent-child 
relationships involving each type of record by providing 
additional information to the data dictionary, either as 
part of the definition of that record or as still another 
type of input data. Reporting capabilities of the data 
dictionary should include the capability of tracing these 
relationships for a specified system, program, or 
transact ion. 

The capability to identify, define, and retrieve data 
dependencies or derivability could also be a valuable data 
dictionary feature. 


3.3 Data Structure - Physical 

Physical data structures involving data elements, 
groups of elements, records, and files are well supported by 
the Data Catalogue system. Definitions of these 
relationships are easy to prepare as input and are well 
described in the various reports available from the system. 

Figure A-3 shows the structure of a group item. Figure 
A-4 illustrates how the structure of a record is indicated 
through use of indentation; each successivly lower level of 
the physical structure, to a maximum of five levels below 
the record, can be shown through indentation. The Cross- 
Reference reports (see fig. A-9 for an elementary item 
example) also document the physical structure; each 
successively higher level of the physical structure is 
listed for each entry. 
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Explicit definitions of transactions (both input and 
output) and reports are not supported in any of the intended 
uses. 6 sage data for an elementary item can specify 
implicitly that a data name is used in processing a 
transaction or producing a report, but this information is 
not reported in an index. These relationships should be 
defined explicitly in any data dictionary system. Another 
important relationship, that of an application system to its 
component programs, processes, and data collections; is 
omitted completely. So references to such a system are 
included in the data. 

A list of data elements used in a specific program is 
given in the Index by Program (see fig. A-6) report. 

However, this data is defined implicitly for each data 
element rather than explicitly by program. 

3.4 Security Level 

Security levels may be specified only for data elements 
(elementary and group items) . Security information for 
records, files, reports, or transactions is not provided. 

The only use made of the security code is its inclusion in 
the Catalogue and Structure reports as an encoded item. No 
report has been produced focusing on or highlighting a 
security level or access to data. 

No provision is made by the Data Catalogue system for 
the security of its own files. The only capabilities 
available to the user in restricting access to system files 
are provided by the operating system. 
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3.5 Programming Aids 


Some direct programming assistance, in the form of 
generation of COBOL source language statements, is available 
from the Data Catalogue system. Testing of this feature was 
omitted, as instructed by the Branch, because of the late 
delivery of that system capability. 

Another capability is the generation of transactions 
for the Data Catalogue system from COBOL source code. It is 
expected that this feature would be a useful tool in 
collecting data elements from existing applications, 
correlating those elements with existing catalogue entries, 
and entering the corresponding names into the catalogue. 
Thus, the system could assist in the maintenance of existing 
programs through improved documentation. 

Another capability which could potentially assist in 
the maintenance function is the Program Revision report. 

This report identifies programs which must be modified as 
the result of a change in the data format or physical 
structure, assuming that the usaqe data in the catalogue is 
complete and accurate. However, Program Revision report 
data is excessively repetitious; an example is shown in the 
appendix, section A. 6. 

Edit data is not included in the system in the form of 
either descriptive material or generation of edit modules. 
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3.6 Test Data 


Optional free-form input may be provided to the system 
describing the value of a data item (see the appendix, 
section A.1). This input could be used to specify the range 
of values for the particular data item. Another possible 
use of this input might be to specify data dependency or 
derivability, but no structured means of specifying such 
data is provided. For example, in a payroll application, 
gross salary might be a function of hours worked and rate of 
pay. To a limited extent, such dependencies could be 
described to the system and could be useful information for 
redundancy analysis. Since any such information would be 
unstructured and not recognized by the Data Catalogue 
system, its usefulness would be limited. 

This system has no test data generation capabilities. 


Q 
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4.0 R ECOHMENDA TIONS 


v 


Based upon experience with the Data Catalogue system, 
the following recommendations are submitted for 
consideration. 


4.1 Data Dictionary 

Data dictionary capabilities could be used profitably 
by the Data Systems Development Branch and should be 
implemented to fulfill Branch requirements for improved 
visibility and control over data resources. Reasons for 
this recommendation include the improved visibility and 
control over data resources which would be provided and the 
assistance which could be provided to the function of 
requirements definition, program development, and 
maintenance. 

It is recommended that the initial use of the data 
dictionary be in support of (1) data gathering for 
documentation, (2) assistance for program development and 
maintenance, and (3) standards implementation. Future 
capabilities should be provided to support functions such as 
performance and redundancy analysis, represen tation of 
additional data relationships, and more advanced programming 
aids. The provision for di rector y-type capabilities (see 
section 5.2) should be considered a function of the systems 
organization. 

It is further recommended that only one data dictionary 
be implemented and used within the Data Systems Development 
Branch. There are several reasons for this recommendation 



in view of the different efforts in progress at present. 
First, many of the data elements for most financial and 
administrative application software systems are the same; 
describing the same data elements to more than one data 
dictionary would be redundant. Next, maintenance of each 
such data dictionary system would require effort. Finally, 
maintenance of the same data for different data dictionary 
systems would invite inconsistency, one of the problems the 
data dictionary is intended to resolve. 

Both short-range (see section 4.2) and long-range (see 
section 4.3) capabilities are suggested, consistent with 
recommendations in MITRE HP-5183 (ref 7) . 

4.2 Short-Range Implementation 

The Data Catalogue system implementation of a data 
dictionary is recommended for short-range use. Modification 
of the system could remedy some of its shortcomings and 
could probably be performed at a lower cost than the 
development of a new system. The Data Catalogue system is 
written in ANSI COBOL. Reasons for this recommendation 
include the following; 

• The Data Catalogue system is installed and working 
under UNIVAC 1108, EXEC 8. It is capable of 
providing significant assistance in requirements 
definition and system maintenance, particularly with 
current COBOL systems. 

• FACS data, which is representative K of much of the 
financial and administrative data maintained by the 
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Branch, is already established in Data Catalogue 
files. The FACS data probably represents some 20 to 
25 percent of the basic descriptive data of this 
type (70 percent of Basic Accounting data, 15 
percent of PMATS and Logistics data) . 

• The Data Catalogue system organization is 

appropriately based on data elements, group items, 
records, and files, consistent with the approach 
discussed by Uhrowczik (ref 2, pp. 340-341). 

Although the system makes no provision for explicit 
definitions of reports, transactions, and systems (a 
serious fault) , these could probably be added for 
less cost than an entirely new system. 

However, it should be noted that, while the system 
currently provides facilities for assistance in defining 
requirements and in other functions, no real assistance is 
provided for the analysis of performance or redundancy for 
evaluating proposed data base desiqns. 

4.3 Long-Ranqe Implementation 

Comprehensive requirements should be defined for long- 
range implementation of a data dictionary system. Directory 
capabilities can be reconsidered at the time the 
requirements are defined. 

t 

As with most computer software applications, the cost 
of the initial development will be only a fraction of the 
eventual cost which must include maintenance of the data 
dictionary system and establishment and maintenance of its 
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data base. Therefore, care must be exercised in the 
definition of requirements. A basic consideration must be 
whether the data dictionary system will be used primarily to 
assist in the design of integrated data bases of whether 
equal importance will be placed on other considerations, 
such as data control, standards, maintenance functions, and 
programming assistance. It is suggested that all the 
capabilities discussed in this evaluation would be 
legitimate requirements and should be defined in more 
detail. 

4.4 Program Network Description 

Another capability which would be useful, both in 
redundancy analysis and in determining the possible effects 
of program, file, or data base modifications, would be that 
of recording and tracing data flow in a network of related 
computer programs. Eelationshi ps of interest are those data 
collections which constitute interfaces among the programs. 
Inclusion of data dictionary information describing data 
interfaces among programs would be a logical development. 

The Data Catalogue system produces an index by Program 
report listing all data items (elementary items only) used 
or produced by a program. Because data for this report is 
taken from usage data (lines 1002-1099) for the elementary 
items, it is liable to be incomplete or inaccurate. Better 
organized input facilities defining specific input and 
output files for each program are needed in order for this 
data to be a useful part of a data dictionary. 
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5.0 MISCELLANEOUS REMARKS 


Several comments about data dictionaries generally and 
the Data Catalogue system specifically are in order, some 
of these are merely reiterations of previous comments, 
whereas others did not seem to "belong" to any other section 
of the evaluation. 


5.1 Data Description Languages 

Data Description Languages (DDL's) are growinq in 
importance and are directly related to the sub-ject of data 
dictionaries. In order to focus on the evaluation of the 
Data Catalogue system, however, virtually no mention was 
made of data description languages as such. Several 
examples of DDL's are contained in the following paragraphs. 

Probably the most common DDL is that used in the data 
division of a COBOL program to describe elementary items, 
group items, records, and files. The same DDL terminology 
used in any COBOL manual is used in defining data for the 
Data Catalogue system. 

The CODASYL Data Base Task Group report of April 1971 
(see ref 6) proposed a data description language for the 
description of a data base. The proposed DDL is largely an 
extension of the COBOL language and has been implemented in 
DMS1100 for the DNIVAC 1100 series and in other data base 
management systems (DBMS) for other computers. The DBTG 
data description language includes facilities for defining 
data relationships such as those mentioned in section 3.1. 
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A technical paper (ref 8) written by Senko, Altman, 
Astrahan, and Fehder proposes another approach to a DDL. 

This data description language was chosen by personnel of 
the Martin-Marietta Corporation for use in their. Research 
Technology Objectives and Planning (RTOP) project in support 
of IDSD. Still other approaches to data description have 
been proposed by Codd (ref 9) and Sibley and Taylor (ref 
10 ). 

The connection between a data dictionary and a DDL lies 
in the description of data relationships for users of the 
dictionary and in the possible generation of source code by 
the data dictionary for inclusion in application systems. 

For example, the Data Catalogue system was designed 
primarily for description of data used by COBOL programs. 
Relationships which are easily defined in COBOL (the 
physical data structures) are meaningful to the Data 
Catalogue system; COBOL source code defining the physical 
structure can be generated by the system. Relationships not 
defined in the standard COBOL (i.e., loqical data 
structures) were excluded in the design of the Data 
Catalogue system; therefore, DBTG-type statements defining 
the logical data structure sets cannot be generated by the 
system. Generation of DBTG-type statements would be an 

important capability if DMS-1100 (or any other system based 

* 

on DB TG- recommended language) were used extensively in the 
inst allat ion . 

5.2 Directory Capabilities 

The directory capabilities of a DD/D system were 
mentioned briefly in section 2.0. Ohrowczik's paper, "Data 


5-2 



Dictionary/Directories, " (ref 2 ) gives an excellent summary 
of directory functions, which he refers to as the "computer 
use mode." These include important capabilities such as use 
of the DD/D system at program execution time (1) to perform 
the actual mapping between logical and physical data 
structures, (2) to centralize the actual data editing 
function, or (3) to centralize actual data conversion and 
compaction functions. Capabilities such as these reguire 
that a common DD/D system be used by the installation 
operating system and by each DBMS used in the installation. 
It is expected that the next generation of computer hardware 
and software may well provide such a common DD/D system. 
However, the prospect of . introducing such a concept into a 
production environment such as the IDSD facility was beyond 
the scope of this -job order. 

another approach has apparently been implemented at the 
Shell Information Center in Houston, as described in a paper 
given at the recent UH/HIS Data Base Conference (ref 11). 

The technigue described involves use of a DD/D system in an 
"envelope preprocessor" cycle to generate an object module. 
This object module then serves as interface between the 
applications program and the data base management system. 
While this approach seems awkward and apparently provides 
only a few of the dictionary functions defined by Uhrowczik 
(ref 2), it does have some advantages. For example, it 
facilitates interfacing more than one DBMS with the DD/D 
without modifying the DBMS, ana it permits use of standard 
data element names independent of the program data names. 
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5.3 Data Explosion 


As stated previously, data from FACS was used to 
evaluate the Data Catalogue system. Of, the FACS data, 
approximately 91 elementary items, 21 group items, 4 record 
formats, and 2 files were selected as input. These data 
items generated over 2,000 input data cards for the Data 
Catalogue system. Because this "data explosion" has been a 
source of some concern, several comments are appropriate. 

Most of the data explosion is inherent in an y data 
dictionary. In some respects, the value of a data 
dictionary is directly proportional to the amount of 
accurate, meaningful, useful data recorded about each data 
item; the same is true of a word dictionary for a specific 
natural language. In this sense, the data explosion is 
desirable. However, both maintenance cost and data 
dictionary usefulness dictate that careful consideration be 
given to what types of data should be kept in the data 
dictionary. Certain items of data are more useful to 
standards control, others to improved documentation or 
maintenance of existing programs, and still others to 

% 

redundancy analyses or system design. If all these needs 
are to be served, the amount of data required by the 
dictionary will certainly be greater than for any single 
need. The Data Catalogue system does facilitate control 
over what data will be maintained. 

Moreover, several techniques can be used to control the 
data explosion to some degree. For the Data catalogue 
system, proper organization of the data can eliminate some 
redundancy; many entries could be eliminated by restricting 
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the recording of data names to those required for file 
definition (FD) in COBOL entries, thus, not permitting 
entries for working storage data, or modifications to the 
system could permit more data per input data card. Some of 
these items should be dicussed in the user manual for the 
system. 


5.4 Maintenance 

As stated in section 4.3, establishment of the initial 
data base is probably the greatest single item of cost. 

Once the initial data base is established, however, it must 
be maintained carefully in order for the data dictionary to 
be useful. Procedures are needed for updating the data 
dictionary automatically as part of the validation and 
review cycle each time an application system is modified. 
Maintenance of the data base should not be expensive, but it 
would require care. 


5.5 Fault Correction 

If the Data Systems Development Branch decides to 
purchase the Data Catalogue system, contractual provision 
should be included for correcting known errors and faults. 
Fault corrections should include the following: 

* Elimination or replacement of all symbols in the 
input and output data which are meaningful only in 
an IBM 360/370 environment. 
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• Elimination of the repetition of data items in the 
Cross-Reference reports, and of groups of lines in 
the Program Revision report. 

• Elimination of erroneously truncated header lines in 
the Structure report for elementary items. 

• Sorting of input transactions by the system prior to 
an initial run or update (as provided for the IBM 
360/370 version) . 

Attempts should also be made to negotiate other 
improvements, such as 

• Provision for the capability of beginning the 
listing for each data item (elementary item, group 
item, record, or file) on a new page. 

• Provision for printing only those data items 
affected by a change, rather than the entire 
Catalogue report. 

• Capability for producing a single report of a given 
type, rather than the requirement that all reports 
in that type be produced (i.e., it should be 
possible to print a new index by catalogue name 
without also printing new indexes of each of the 
other types) . 

• Provision for the catalogue report format which 
would be more useful at this installation if the 
elementary item usage data were organized 
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differently. Also, system and program 
identification provisions are inadequate. The 
following general approach is suggested for 
organizing and formatting Catalogue report usage 


data 

output: 




Using 

System 

lE23£3ffl 

Pat a_ name 

Format 

0se 

organization 

FACS 

P3860 

FS~1 

X (1) 

CREATE 

FMD 



WS-1 

X (1) 

CREATE 

FMD 


P3870 

FS-3 

X (1) 

READ 

FMD 

P497 

— 

- - 

— 

— 

— 


This data would replace lines XXOO, XX01, and XX02 
in the Catalog report (see appendix, section A.1) 
for each elementary item. 

• Encoded data (specifically for the Data Catalogue) 
should be interpreted in the output reports rather 
than appear as encoded data. 

5.6 Data Dictionary Names 

Care should be exercised in the assignment of names in 
a data dictionary. In order for naming conventions to be as 
meaningful as possible to users of the dictionary, 

j 

responsibility for this function should be centralized as a 
data base administrator function. Otherwise, data 
dictionary names will be assigned one application system at 
a time. As a result, those systems described to the 
dictionary first would probably establish name standards by 
default. 
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APPENDIX 
REPORT EXAMPLES 

Several examples of reports produced by the Data 
Catalogue system are included for illustrative purposes in 
this appendix. Data in these reports is primarily from 
FACS; however# some references are made to elementary items 
and transactions (shown as "records") from IFMS. 

A.1 Elementary Items 

Two examples of elementary items are presented - FOND 
SOURCE (fig. A-1) and PRIMARY WORK CODE (fig. A-2) . Both 
are included in the Catalogue report, with some variations 
in their contents. Line numbers are listed in the far right 
column. 

Item descriptions may be recorded on lines 0001-0099 
(actually shown on lines 0001-0004 for fund source, 0001- 
0005 for primary work code) . Keywords (up to 10 per item) 
begin on line 0001. Remaining lines are in free-form with 
contents at installation discretion. 

Source data (lines 0100-0199) needs careful 
preparation. It should involve study of the origin and 
responsibility for each particular data item. Lines 0101- 
0199 are recorded in free form. 

Value description is unstructured, free-form data 
recorded in lines 0200-0299. Installation standards could 
be imposed to structure the value data for optimum 
usefulness. These standards could consist of fixed codes 
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and descriptive text. The fund source entry (fig. A-1) 
provides one example of possible use. 

Lines 0300-0999 are currently not' used by the Data 
Catalogue system, and could be used at the discretion of the 
installation, particularly if modification of the system 
were undertaken. Some possible uses of these lines would be 
for the designation of those systems (such as FACS, 
Institutional Management Accounting System Phase B (IMAS-B) , 
or PH-497) in which the element is used, designation of 
dependency on other elements, or designation of specific 
derivability algorithms. 

Usage data is recorded on several successive groups of 
lines, ranging from. 1000 to 9999. Up to 90 qroups of usage 

data may be recorded (lines 1000-1099, 1100-1199, 9900- 

9999) . Generally, 1 to 3 lines will be needed within a 
group, which is associated with a specific data name. The 
first specifies the data names (the " BAL Symbol" and "DBD 
Name" fields are IBM 360/370 terms without meaning for this 
evaluation) ; the second specifies element format; and the 
third (and succeeding lines, if necessary) specify programs, 
reports, and other "element usages." Since only 1 to 3 
lines are generally needed for a particular data name, the 
100 lines available are wasteful; standards for data names 
could change this condition; otherwise, the system should be 
modified to increase the number of permissable names by a 
factor of at least 10. ' 



SECTION ll ELEMENTARY ITEMS 


CATALOGUE NAME 


CATALOGUE REPORT 


REVISION NUMBER- 
DATE DP LAST REVI 
TYPE OF UPDATE- 


PERMANENT 


»»♦ FUND-SOURCE 


DES CRIPT ION 

KW = FS 

CODE THAT IDENTIFIES FINANCING APPRPP3 J ATIDN IN TERMS 
OF CURRENT ADMINISTRATIVE CLASSIFICATION USED 8 Y NASA 
HE ADQUAPTERS TO MANAGE FUNDS. ; 


DEPT- JSC-FIN-MGMT-DIV 


PRDG/A>PL ICATION/SYSTEM-BASIC AMOUNTING 


VALID FUND SOURCES ARE PROVIDED VIA A TABLE WITHIN 
THE JSC BASIC ACCOUNTING SYSTEM 1PRQJECT 25201. 

VALUE DESCRIPTION— 

LODE ~ OESCR/IPTToN “ . 

1-3 RE5EAKC H ANO PROGRAM MANAGEMENT _ 

I PERSONNEL SERVICES 

2 TRAVEL 

3 OPERATION OF INSTALLATION 

» RESEARCH AND OEV EL DPMENT PROGRAM 

5-8 CONSTRUCTION OF FACILITIES 

__ 5 CONSTRUCTION OF FACILITIES EXCEPT FOR 

FACILITY PLANNING AND VARIOUS LOCATIONS 
f inal DESI GN : 

7 VARIOUS LOCATIONS 

8 PRELIMINARY DESIGN 

T TRUST FUND 

Q UNFUNDED TRANSACTIONS 


IMPLEMENT ATIDN STANDARDS 

DATA NAME= M-FS 0 A L SYM= DB D= 

LENGTH- I L AN&=COBQL FORMATED ISPL AY J UST/S YNC« J DYNAMI C*C 


COBOL PI CTURE=X 
COPE NAME OPTIONS 

P P3860 U 

DATA NAM E~ T-FS 

DATA NAM6=WS-FS 

DATA NAME= P— M— FS 

DATA NAME=P-T-FS 

DATA NAM£= F-FS 

LENGTH^ I LANG= COBOL 

COBOL PI CTURE a X 

P P3650 R 

DATA NAME=S~FS 
DATA NAME=ST-F S 

DATA NAME= F-C-FS 

data name=m-fs 

LENGTH^ 1 L AN G~ COBOL 

COBOL PI CTUKE=X 


VALUE= 

FR£3_* SECURITY 


8 AL SYM - 
BA L SYM = 


DEPARTMENT NAME 


SAL SYM- 
8ALSYM- 


FDftMAT=0ISPL AY 

VMUE= 

M 0001 


JUST /SYNC 


DBD* 

DBQ» 

= J DYNAMIC* 


BAL SYH- 
BAL SYM- 
BAL S YM ~ 
BAL SYM- 


FDPM AT-D I SPL A Y 

VALUE= 


Figure A-l. — Example of Catalogue Report, Fund Source Elementary Item. 


ORIGINAL PAGE $ 


- Q— A^_T — A 

CATALOGUE 


REPORT 


SECTION I. elementary items 


CATALOGUE NAME 


\E VI SION NUMBER- 
DATE pf LA ST RE VI 
TYPE Df= UPDATE- 


PERMANENT 


*** PPIM4RY-W:RK-CODE *** 


DESCRIPT ION • 

KW= PWC 

T-US FIELD IS THE JSC PORK BREAKDOWN STRUCTURE COPE* 
VHICH IS A UNIFORM CLASS I F IC AT ION AND IDENT IE K A If ON 


hj j ^ ri a * j i 



PROGRAMMING. BUDGETING. AND ACCOUNTING. 

- — SOURCE R E S P □ N S I B IL iT r'— ~ 


DE PT = JSC-F IN-MGMT-D I V PROG/A* PLICATION /SVSTEH-fl A SI C ACCOUNTING 

FORM NO.* . 


VALID PRIMARY WORK COOES ARE PROVIDED VIA A TABLE 
WITHIN THE JSC BASIC ACCOUNTING MGMT DATA SYST ‘ 


VALUE DESCRIPTION- 

MUST BE VALID EUR SPECIFIED FUND SOURCES (2) 


AND PROGRAM YEAR f 5 1 


IMPLEMENTATION STANDARDS 

ATA NAM E=T-PW C 


IE NGTH= 9 LAN6=C0B0L FORMAT "DISPLAY JUST/SYNC = J OYNAMIC=t 


CODE NAME 
386 


DATA NAM E= WS— PWC 


DATA NAM E= P-T -PWC 


OPTIONS CYCLE FREQ. SECURITY DEPARTMENT NAME 
U M. 0001 


SAL 5YM= DBD* 






SAL SYM* 




LENGTH* 9 LANG- CO SOL FORM AT* D I SPLAY 

COBOL PI CTURB = X ( 9 ) 


P P3850 R M 0001 

DATA NAMfc i k zML 

DATA NAME=I£-PWC 

DATA NAHE*M-PWC : 

LENGTH* 9 LANG=COBOL FORM AT*Q I SPLAY 


J UST/S YNC -J DYNA Ml C=C 


SAL SYM = 
SAL S YH = 


J UST/S YNC *J DYNAMIC-C 


COBOL PI CTUkE=X ( 9 ) 
DATA NAME=F2“PWC 
N 


COBOL PlCTURE=X(9l 


VALUE* 

BAL SYM= 


9 LANG*CGBOL FORM AT=D I SPL AY 


COBOL PI CTURE=X( 9 1 


P3870 / 


J UST/S YNC = J D YNAMI C=C 


PRIMARY-MORK-ClQDE.. 


Figure A-2. - Example of Catalogue Report, Primary Work Code Elementary Item. 






A. 2 Group Items 


The entry for MASTER SEQUENCE is presented to 
illustrate the Catalogue report for group items (fig* A-3). 
The format is the same as for elementary items for 
descriptive text (lines 0001-0099). Lines 0100-0999 are not 
used by the system, with the same options available for 
installation use as lines 0300-0999 of the elementary item 
entries (see section A.1). 

Lines X000 are used to specify data names for the group 
items (up to 9 names) . corresponding to the data name 
specified in line N000, lines N001-N999 may be used to 
specify the structure for that group item together with 
indexing data. Each element of a group item may also be 
referenced to a specific data name entry in the 
corresponding elementary item through designation of the 
line number for that data name. 

Subgroups may be specified by treating each subgroup as 
an elementary item. Fillers, as defined for COBOL programs, 
may also be specified. The Catalogue report will show each 
level of subgroup as indented from the previous level, the 
indentation being repeated until the lowest, or elementary 
item, level is reached. 
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C A T A L 

OGUE REPORT 

REVISION NUMBER- 
DATE OF LAST REVISION- 

U 

02/1 S/75 


- £ 



TYPE QF UPDATE- 

PERMANENT 

- 

catalogue name 

REV* 



LINE 

NUMBER 

DEFINED 
ON PAGE 

*♦* MASTER-SEQUENCE 

#*» 

DESCRIPTION— 





1 

1 

KW= SQRT-S6Q 

SORT SEQUENCE CP FACS MASTER,FIL8 


0001 

0002 



1 

1 

CONI -MOD f RECORD TYPEi P’rfC ? fi At PY, FS , OBJECT 
NORK-STATUSCODE AMP F\U SOURCE COPE 

class. 

0003 

000* 



IMPLEMENTATION S JAtt I>Aft_D.3r-- 


1 

DATA NAME* M'S OR I -SEQ 

SYMBOL * 

1000 


SECURITY- FREQUENCY OF ACCESS* 


1000 


GROUP IT EK STRUCTURE 


1 

FROM TO 
QOi 

ITEM CATALOGUE NAME 
CONTRACT Oft— MOO 

LINE LENGTH RD INOEX DEPEND 
1000 

1001 

60 - - 

l 

001 

JSC - CO NT ft ACT— NO 

1000 


33 

i 

001 

JSC-CDNT ft ACT-NO-MOO 

1000 


36 

i 

001 

MAS TEK— RECUR D~TY PE 

1000 

1002 

36 

1 

001 

PR [ MAR Y'MORK -CODE 

1000 

1003 

48 

i 

001 

UORK-ST ATUS-CQOE 

1000 

100* 

66 

1 

001 

FlLE-SCURCE-CODE 

1000 

1007 

29 



[ MPL EMENT AT ION STANDARDS- 




1 

Data name* 

: T-SURT— S EQ 

SYMBOL* 

2000 



security* 

FREQUENCY OF ACCESS* 


zmi 



— MP. ZT.CM-5TflUCJ.DREr.r- 


1 

FROM 

TD 

001 

ITEM CATALOGUE NAME 
CONTRACT OR— MOD 

LINE LENGTH RD INDEX DEPEND 
2000 

2001 

6B 

1 


001 

JSC -CONTRACT-NO 

1100 


33 

1 


001 

JSC— CUNT RACT— NO-MOD 

1100 


34 

l 


001 

MASTER-RECORO-TYPE 

1100 

2002 

36 

l 


M U- 

PRIMARY-HOftK-CODE 

JOOQ 

2003 

4B 

1 


001 

WORK-STATUS-CODE 

1100 

2006 

66 

1 


aoi 

FILE-SCURCE-CDDE 

nog 

2007 

29 

IMPLEMENTATION STANDARDS 

1 

DATA 

NAME- 

PUR-SORT-SEQ 

SYMBOL* 

3000 



sEc yft i jy= _ ,. .3 000 


-&EIUP- JLL£E-^iaUCJm£=r: _ 


l 

FROM TO 
001 

ITEM CATALOGUE NAME 
CONTRACTOR— MGO 

LINE LENGTH RD INDEX DEPEND 
3000 

3001 

68 

’ 1 

ooi 

JSC- CUNT RACT-ND 

1200 


33 

1 

001 

. JSC-CDNTRACT-NO-MDD .... 

1600 


34 

l 

001 

MASrtK-RECURD-TYPE 

1200 

3002 

36 

1 

001 

.-FILLER 

002 0 

3003 


MASTER-SEQUENCE 


PAGE B2 


Figure A-3. — 


Example of Catalogue Report, Group Items* 



A. 3 Records 


The FACS TRANSACTION RECORD (fig. A- 4) is presented as 
an example of a Data Catalogue entry for a record. Again, 
lines 0001-0099 are used to specify descriptive data. Lines 
0100-0999 are not used by the data and would be available if 
the Data Catalogue system were modified to accommodate the 
definition of relationships among records. 

For each data name assigned to a record, the user may 
specify the usage (using program, language, and use 
function) associated with that data name and the 
corresponding record structure; the example used here shows 
varied structure representations corresponding to the data 
names TRANS, TRANS- 1 0- 30- 35, TRANS-TR, and WORK-RECORD. 

A. 4 Index Reports 

Several index reports are produced by the Data 
Catalogue system. Those selected for examples (figures A-5 
through A- 8) include a single page from the Index by 
Catalogue Name, the Index by Program, the Index by Data 
Name, and the Index by Departmental Use. 

Given the Catalogue Name, any elementary or group item, 
record, or file entry in the Catalogue report can be located 
in the Index by Catalogue Name (figure A-5) . Entries are 
sorted alphabetically. Three columns of data are listed: 
the Catalogue Name, type of entry, and page location in the 
Catalogue report. 

For any program recorded as part of the usage data for 
an elementary item or record, a listing of those entries and 
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REVISION NUMBER- 

11 


SECTION 3. SEGMENT ITEMS 






DATE OF LAST REVISION- 
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TYPE OF UPDATE- 

PERMANENT 


CATALOGUE NAME 


REV. 
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LINE 

DEFINED 








NUMBER 

ON PAGE 

*** TRANSACTION-RECORD 

*** 



DfcSCftIPT ION 







I 

KW*TRANS 



0001 




1 

UPDATES THE FACS MASTER-FILE 



0002 


4 

' 'm 




_ -"1 MR Iktt ENT A T I ON S T AN P AR PS— 




£ 


9 

DATA NAME^TRANS 


SYMBOL =******** 

1000 





IMS SEGMENT N AM E= ***** **♦ 
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- 


USAGE LIST 








CODE 
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CODE 
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9 
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LINE 

LEN RD INDEX DEPEND 

KEY 
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1100 
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l 
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IMS SEGMENT NAME®******** 



2000 



Figure &-4. — Example of Catalogue Report r Record. 
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Figure A-4. — Example of Catalogue Report, Record (Continued). 
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FROM TO ITEM CATALOGUE NAME 

LINE 

LEN RD INDEX DEPEND 

KEY 




1 

1 

001 MODIFICATIDN-TYPF 
Q01. -REPORT-CODE 

1600 

1400 


5101 

5102 

39 

KQ 



1 

I 

001 PROC-PLACEMENT-CODE 
001 PRC£~P LACE-CODE-i 

1000 

1000 


5103 

. 88 
52 



1 

1 

001 PRQC-P LACE-CODE— 2 

001 C □ NT R At T - 0 AT E 

1000 

L200 


5104 

53 

10 



1. 

l— _ 

OOi CONTRACT -COMPL-DATE 
001 CGNTR-CGMPL-MGNTH 



5105 

TO 

1 4 



1 

l 

001 FILLER 

001 LABOR— SJ R-PREFER-COO 

1000 

0004 

5106 

35 



1 

1 

001 . KIND-OP-ACT ION 
001 REASON-NUT-SMALL-BUS 

1000 

1000 


5107 

5108 

35 

56 



I 

l 

00 i CONTRACT-TYPE 

001 EXTENT-OP-COMPET IT 1.0 

1100 

1000 


5109 

5110 

14 

28 



1 

J 

OOI SMALl-BJSl NESS— SUBCT 
001 PRQCJ R-SYNGPS IZ ED 



5111 

5112 

61 

51 



L 

I 

001 NEM-T ECHNOLOGY-REPT 
OOI GEOGPAPNIC-UISTRIB 

1000 

1000 


5113 

5114 

41 

30 



1 

l . 

001 SUPPORT -SVC-CONTRACT 
001 COST-PERFORMANCE 

1000 

1000 


5115 

5116 

63 

20 






T*ANS*C T ION-RECORD 





Figure A- 

-4. - Example of Catalogue Report, Record (Concluded) . 






XI-V 


1 

0 A 

I A CATALOG.] 

F 

REPORT HATE- 

n?/?7/7«i 





RE VI 51 ON NUMBER- 

n 

i 

N D E X BY 

catalogue n 

A M E 

DATE LAST RE VI SION- 

02/15/75 





TYPE OF UPDATE-. 

PERMANENT 

catalogue name 

SECTI ON 

PAGE 

CATALOGUE NAME 

SECTION 

PAGE 

A A- EX AMPLE- FIVE 

DATA BASE 

1 

CONTRACT-NUMBER 

GROUP 


AA-EXAMPt E-F3UR 

FILE 

1 

CONTRACT-TYPE 

ELEMENTARY 

14 

AA- EX AM PL E-ONE 

ELEMENTARY 

1 

CONTROL-NUMBER 

ELEMENTARY 

15 

aa-example-three 

SEGMENT 


CONTR-AND-MOD 

GROUP 


AA-EXAMPLE-TWD 

GROUP 


CUNT R-CGHPL-DAY 

ELEMENTARY 

15 

ACCEPTANCE- AMOUNT 

ELEMENTARY 

1 

CONTR-COMPL -MONTH 

ELEMENTARY 

15 

ALLOTMENT-BALANCE 

ELEMF NTARY 

1 

CONTR-COMPL-YEAft 

ELEMENTARY 

16 

alLotment-issues 

ELEME NTARY 

l 

CUNT -CQMPL- DATE 

ELEMENTARY 

17 

ALLOTMENT-RECEIPTS 

ELEMENTARY 

1 

CONT— ND-PFX 

ELEMENTARY 

17 

ALLDT-AVAILAftLE-REC 

ELEMENTARY 

2 

■ ■■ 

ELEMENTARY 

18 

ALLOT- I SSUES-F S 

ELEME NT ARY 

2 

CONV *-PWA- ISSUES 

ELEMENTA* Y 

18 

AL LOT -ISSUE S-MA 

ELEMENTARY 

2 

CUNV •-PWA-RECEIPTS 

ELEMENTARY 

18 

ALLOT-ISSUES-PRIOR-D 

ELEMENTARY 

2 

CORRECT ION-INDICATOR 

ELEMENTARY 

16 

AL L OT- ISSUE S-P Y 

ELEME NTARY 

2 

COST 

ELEMENTARY 

18 


wnrrmr mm 

2 

COST-ACCOUNT IMG 

elementary 

19 



3 


ELEMENTARY 

20 

APPROPRIATION 

ELEMENTARY 

3 

CUT-OFF-DATE 

GROUP 


ASSIGNMENT-AMOUNT 

ELEMENTARY 

3 


FL FMFNTAR Y 

21 

AS-DF-OATE 

ELEMENTARY 

3 

CUT-OFF-DAY 

ELEMENTARY 

21 

AS-OF-OAY 

ELEMENTARY 

3 

CUT-OFF-MONTH 

ELEMENTARY 

21 

AS-Qf-HJVTH 

ELEMENTARY 

A 

CUT-OFF-YEAR 

ELEMENTARY 

22 

AS -OF- YEAR 

ELEME NTARY 

A 

DAT F-OF-L AS T— C HAN G F 

GROUP 


AWARD-INDICATOR 

ELEMENTARY 

5 

DATE-OF-LAST-CHANGE 

ELEMENTARY 

22 

BASE 

ELEME NTARY 

5 


ELEMENTARY 

23 

CARRIER- ID 

ELEMENTARY 

6 

DISBURSEMENTS 

ELEMENTARY 

23 

CARRIER-RQ 

ELEME NTAP.Y 

6 

DOLL AR-AMQUNT 


24 

CAP RIER-1A 

ELEMENTARY 

6 

ENGINEER ING- HOURS- LD 

ELEMENTARY 

25 

CHANGE ’“IN DILATOR 

ELEME NTARY 

6 


ELEMENTARY 

26 

COMMITMENTS 

ELEMENTARY 

6 

ESTIMATED-FEE 

ELEMENTARY 

27 

CONTftACTOft-C ITY 

ELEMENTARY 

7 

EXT ENT— OF— COMP FT IT 10 

ELEMENTARY 

28 

CONTRACTOR-DIVISION 

ELEMENTARY 

a 

FILE— SQUftCE-CEJDE 

ELEMENTARY 

29 

CONTRACTOR-MOD 

GROUP 


FUND-SOURCE 

ELEMENTARY 

29 

CONTRACTOR-NAME 

ELEMENTARY 

8 

F— PFX 

GROUP 


CONTRACTOR-STATE 

ELEMENTARY 

9 

FI i- If MS 

SEGMENT 


CUN TRACT- ADM- OELEGAT 

ELEMENTARY 

9 

GEOGRAPHIC-OISTftia 

ELEMENTARY 

30 

CON TR ACT-CDMPL-DATE 

GROUP 


GL1-IJEMS _ . 

SEGMENT 


CON TRACT- DATE 

ELEMENTARY 

10 

G13-IFMS 

SEGMENT 


CONTRACT- I D-CQDfc 

ELEMENTARY 

11 

G21-IFMS 

- SEGMENT 


CONTRACT-MOD-DATE 

GROUP 


G22-IFMS 

SEGMENT 


COM TRACT- MOD- DAY 

_ E_L.EME_NTA.RY _ 

- 12 


. SEGMENT 


Contract- mod-month 

ELEMENTARY 

12 

HI 1— I FMS 

SEGMENT 


CON TRACT- MOD- YEAR 

ELEMENTARY 

12 

H12-IFMS 

SEGMENT 


CONTRACT-NO-BASE 

ELEME NTARY 

13 

H13— If MS 

SEGMENT 


CONTRACT- VO- 1FP 

'ELEMENTARY 

13 

INIT I AL-CONT R- DATE 

GROUP 


CON TRACT - NQ-2FP 

ELEMENTARY 

14 

IN I T I AL-CQNT R-OAY 

ELEMENTARY 

31 

- PAGE 1 - 




Figure A- 5. — Example 

of Index by Catalogue 

Name. 





ORIGINAL PAGE IS 




DATA C. A T A i n r, t/ F 


ftFPHftT DA TF— fW/7 7/75 





REVISION NUMBER— 11 



INDEX SY PROGRAM 


DATE LAST REVISION- 02/15/75 





TYPE OF UPDATE- PERMANENT 



PROG. NAME-P3860 



CATALOGUE NAME 

PAGE 

CATALOGUE NAME 

PAGE 

CATALOGUE NAME PAGE 

CON TRACT- TYPE 

14 

PROGRAM-YEAR 

53 


CON TRAC T-N0-2FP 

14 

REC-CRE AT ION-DAY 

57 


CONTRACT-NO- IFP 

13 

tfORKt N3-ST0PAGE-RCD 

107 


CQNTR-COMPl-DAY 

15 

PURGE-RECORD 

101 


CONTR-COMPL-YEAR 

16 

PRGC- PL AC EMENT-C ODE 

51 


CONTR-COHPL-MONTH 

15 

WORM NS -STGRAGE-RCD 

107 


COST-ACCOUNTING 

IS 

TRANSACTION-RECORD 

102 


OBL IGATiONS 

42 

WORKI NG-STORAGE-RCO 

107 


COST 

18 

PRI-HOPK-CGOe-PROJ 

50 


OBL IGATIONS 

42 

WORKI NG-STORAGE-RCO 

107 


CUT-OFF-MONTH 

21 

PROC-PL AC E— CODE-i 

52 


CUT-OFF-DAY 

21 

WORK I NG-STORA GE-RCD 

107 


DISBURSEMENTS 

23 

MASTER-RECORD 

»7 


DATE-DF-LAST-CHANGE 

22 . 

PROC— PLACE-CODE— 2 

53 


CUT-OFF-YEAR 

22 

PHYSI CA L-COMPLET E-DT 

48 


DISBURSEMENTS 

23 

TRANSACTION-RECORD 

102 


ENGINEER ING-HQURS-LD 

25 

TRAILER-TITLE 

64 


ESTIMATED-COST 

26 

REGULAR— H QURS-l D 

58 


ESTIMATED-FEE 

27 

REPORT-CODE 

60 


FILE-SOURCE-CODE 

29 

REC-CRE AT ION-YEAR 

58 


FUND-SOURCE 

29 

TRAI L€R— RCD-COUNT 

63 


IN IT1AL-CONTR-MONTH 

31 

physical-complet e-dt 

48 


IN IT1AL-CONTR-DAY 

31 

,,TRANSACTI CN-RECQftD 

192 


JSC-CONTR ACT-NQ-MDD 

34 

MORK-ST ATUS-COOE 

66 


JSC-CQN TRACT- NO 

33 

REC-CRE AT ION-MONTH 

57 


IN I T I AL- OBLIGATI UN 

32 

TRANSACTION-RECORD 

102 


OBL IGATIDN-REGUIRED 

43 

RECORD-COUNT 

56 


INITIAL-OBLIGATION 

.32 




IN ITI AL-CDNTR-YEAR 

32 




OBJECT-CLASS-1-3 

41 




MAS TFR-RE CORD- TYPE 

36 




OBL I GA T ID N- REQUIRED 

43 




COMMITMENTS 

6 




• CONTRACTOR-NAME 

a 




CONTRACT-DATE 

10 




CONTRACT-NO-BASE 

13 




ANARD-INDICATOR 

5 




MET HO D-OF-AUTHORI £AT 

37 




M INORITY-CONTRACT 

38 




MODIFICATION-TYPE 

39 




OVERT IM E- HOUR S- LD 

44 



• / 

MASTER-RECORD 

97 




PR I M ARY- WDRK-C OOt 

48 
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/ Figure A-6. — Example of Index by Program, 







REVISION NUMBER- 

11 

i 

N D E X 3 Y D 

A T A N 

A M £ 

DATE LAST REVf SION 

- QZ/15/75 _ 





TYPE Of UPDATE- 

PERMANENT 

DATA NAME 

SECT! GN 

PAGE 

DATA NAME 

SECTION 

PAGE 

AA-EXAMPLC- IA 

ELEMENTARY 

i 

ti-MGO 

ELEMENTARY 

34 

A-PREV-MO-AOJ 

ELEMENTARY 

1 8 

Cl— NEW— TECH 

ELEMENTARY 

41 

B-PR EV-KO-ADJ 

ELEMENTARY 

42 

C1-G8L I-REG 

ELEMENTARY 

43 

697-BASE 

elementary 

5 

Cl-PIC 

GROUP 

80 

1 B97-C0N TR-DATE 

ELEMENTARY 

mmvmm 

C 1— POP— C I TY 

ELEMENTARY 

7 

897-CaNTft-MQQ 

GROUP 


ti-PGP-STATE 

ELEMENTARY 

9 

897-COST-ACCTG 

ELEMENTARY 

&gH 

Cl-PPC 

ELEMENTARY 

51 

B97-EC0ST 

ELEMENTARY 

HH 

Cl-PREF 

ELEMENTARY 

20 

B97-6FEE 

ELEMENTARY 

27 

Cl— PROP-HOME 

ELEMENTARY 

54 

B97-MIN-6US-CQN 

ELEMENTARY 

38 

Cl-REC-TYPE 

ELEMENTARY 

36 

B97-M0D 

ELEMENTARY 

34 

Cl-RNSB 

ELEMENTARY 

56 

8 97-3 SL -NEEDED 

ELEMENTARY 

43 

Cl— RPT-SB-SUB-CONT 

ELEMENTARY 

61 _ . 

S97-PFX 

ELEMENTARY 

45 

tl-SCHED-QNLY 

ELEMENTARY 

40 

B97-PHY-C0MPL-DT 

ELEMENTARY 

43 

C 1-SUP -5 VC 

elementary 

63 

097-TYPE-hOO 

ELEMENTARY 

3 9 

CI—SVNOP 

ELEMENTARY 

51 

CD- MM 

ELEMENTARY 

15 

C 1— TYPE— CQNT 

ELEMENTARY 

L4 

CT-DA 

ELEMENTARY 

21 

Cl-TY P E-EFFORT 

ELEMENTARY 

64 

CT-MG 

ELEMENTARY 

2 i 

'Cl— X COST 


26 

CT-YR 

ELEMENTARY 

22 

Cl-KFEE 

ELEMENTARY 

27 

C-CUMM 

ELEMENTARY 

6 

C2-CIC 

ELEMENTARY 

11 

C-COST 

ELEMENTARY 

18 

C2-COMP— DAT E 

ELEMENTARY 

17 

C-DIS6 

ELEMENTARY 

23 

§j\,\ iwmmmmmmmmm 

GROUP 

72 

c-eng-his 

ELEMENTARY 

25 

C2— CONT-BAS E 

ELEMENTARY 

13 

C-3BL I 

ELEMENTARY 

42 

C2— CUNT— DAT E 

ELEMENTARY 

10 

C-3VT-HRS 

ELEMENTARY 

44 

C2-C0NT-PEX 

"elementary 

17 

C-P 3 E V-MO- ADJ 

elementary 

6 

C2 — C ON— A DM- OE L 

ELEMENTARY 

9 

C-*EG-HRS 

ELEMENTARY 

58 

C2-C0ST-ACCT 

ELEMENTARY 

19 

Cl-CIC 

ELEMENTARY 

ll 

C2— CDSTrPR EF 

ELEMENTARY 

20 

Cl-CDMP-DATL 

ELEMENTARY 

17 

C2-EST-fE£ 

ELEMENTARY 

27 

Ci-CONT ... _ . 

GROUP. 

. _ _72 

-C2-fcST-F£E 

ELEMENTARY 

26 

C L-CGN T-8A S£ 

ELEME NT ARY 

13 

C2-EXT-COMP 

ELEMENTARY 

28 

C 1-C3NT-OATE 

ELEMENTARY 

10 

C2— GEO-DIST 

ELEMENTARY 

30 

C l-CONT-DIV 

ELEMENTARY 

& 

C2— K I NO-ACT 

ELEMENTARY 

15 

CL-C3NT-NAME 

elementary 

e 

C2-LS-PREF 

ELEMENTARY 

35 

Ci-CONT-PfX 

elementary 

17 

C2-MD-TP 

ELEMENTARY 

39 

C 1-C3V-ADM-DEL 

ELEMENTARY 

9 

C2-M IN-BUS 

elementary 

38 

C l-COST-AC C T 

ELEMENTARY 

19 

C 2-MOD 

elementary 

34 

Cl-EST-CDST 

ELEMENTARY 

26 

C2-NEW-TECH 

ELEMENTARY 

41 

C 1-EST- FEE 

ELEMENTARY 

27 

C 2 -0 BL I -N £ EOE D 

ELEMENTARY 

43 

C-ir EXJ- CUMP 

EJLEMEJXr AKY_ 

23. , . 

X2-P.1C . . 

GROUP 

SB 

Cl-GEa-DIST 

ELEMENTARY 

30 

C2-PPC 

ELEMENTARY 

51 

Cl-KIND-ACT 

ELEMENTARY 

35 

C2— PROP— HpHE 

ELEMENTARY 

54 

Cl-LSAP 

ELEMENTARY 

35 

C2-AEC-TYPE 

ELEMENTARY 

36 

C l-MD-TP 

ELEMENTARY 

39 

C2-RPT-S&-SU8C.GNT 

ELEMENTARY 

61 

C1-MI.V-6US 

elementary 

33 

C2-S B-REASON 

ELEMENTARY 

56 

PAGE 



Figure A-7. - Example of index by Data Name. 



g n u f. a t A t n g u f . — report date.- 02/27/75 


l 

N D E X 

B. Y ..SOURCE DEPART 

M E N T 

REVISION NUMBER- 11 

DATE LAST REVISION- 02/15/75 



DEPT. NAME=LFMS INFORMATION 


TYPE OF UPDATE- PERMANENT 

CATALOGUE NAME 

PAGE 

CATALOGUE NAME 

PAGE 


PRIOR-TRANSACTION- ID 

50 

ALLOTMENT-BALANCE 

1 


PR IOR-PWA-TAAN5-C0NT 

$0 

OLD-ACCEPTANC E-AHT 

44 


CONTROL-NUMBER 

15 

ULD-RA-RECE1PTS 

44 


RESEKV.-PWA-BALANCE 

GO 

5U8-KA-PWA-RECEIPTS 

62 


SU8-ALLGT-R ECE IPTS 

61 

RA-1 SSUES-PY 

55 


CORRECTION- INDICATOR 

la 

A S- OF -0 ATE 

3 


CDNV,-PWA-RECEIPTS 

18 

ASSIGNMENT-AMOUNT 

3 


CONV*-PWA- ISSUES 

18 

APPROPRIATION 

3 


C3NV.-PWA-BALANCE 

18 

AMENDMENT-NUMBER 

3 


RE SPONSIBLE-ORGN 

61 

ALLOT-S Uft— I SSUED-S JS 

2 


RA- ALLOT- A VA IL .-Q IFF 

54 

ALLOT— I SSUES-PY 

2 

- 

RA- I SSUES-PWC 

55 

ALLOT-! SSUES-PRI OK-D 

2 


USER-ID 

66 

ALLOT-! SSUES— MA 

2 


TRANSACTION-CODE 

64 

ALLOT-! SSUE5-FS 

2 


DOLLAR- AMOUNT 

24 

ALLOT-A VAX LABLE-REC 

2 


RESERV.-P WA-I SSUES 

60 

5UB—ISS UE D— BALANCE 

62 


RE IMB.OR0ER-NUM8ER 

59 

PRI OR-PWA— TRANS- I D 

50 


. SU0-I SSUEO-REC E IPTS 

62 

SUBAUTHQft I2AT ION— I D 

61 


RESERV.-PNA-TtCEIPTS 

60 

UPDATE-RA-RECEIPTS 

66 


PRIOR-CONTROL -NO* 

49 

CHANGE- INDICATOR 

6 


TYPE-OF-TRANSACTIUN 

65 

CARRIER—! A 

6 


REIMBURSABLE-ORDER 

59 

CARRiER-RO 

6 

\ 

RA- I SSUES-HA 

55 

CARRIER-ID 

6 


MET HO D-QF- AUTHOR I TY 

37 

SUB— I SS UE D-I S SUES 

62 


R A-SUB- ISSUED-REC E IP 

56 

RA- I SSUES— PRI Qft-DAT E 

55 


UNASSIGNED-BALANCE 

65 

PRIOR-AMENDMENT-NO, 

49 


RA-ISSUES 

55 




SUB-AUTH*- IDENTIFIER 

6i 




UPDATE-AMOUNT 

65 




TRANSACTION-DATE 

64 




Pft IOR-*P WA-TR AN 5-QA TE 

50 




TYPE-OF-FUNDING 

65 




RA-KECEIPTS 

5$ 




RA-AVAILABLE-RECE 1PT 

54 




TRANS'* I D 

64 



> 

SUB-RA-PWA- ISSUES 

62 




SUB-RA-PWA-BALANCE 

62 




RA-BALANCE 

55 




NEW- ACCEPTANCE- AMT 

41 




NEW— RA-R ECE IPTS 

41 




ACCEPTANCE- AMOUNT 

1 




ALLOTMENT-RECEIPTS 

1 




ALLOTMENT- I S SUE S 

1 
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Figure A-8. — Example of 

index by 

Source Department* 


their locations are provided by the Index by Program (fig* 
A-6). At least two problems exist for this index. First, 
the index names are not sorted alphabetically. Finally, the 
entries are provided implicitly in data recorded for 
elementary items and records; the listing would probably be 
more accurate if the records were specified explicitly for 
the particular programs. 

The Index by Data Name (fig. A-7) lists all data names 
in the catalog alphabetically. The type of entry and 
Catalogue report page number for that data name are given. 

Elementary items used by a specific department as 
defined implicitly in the usage data, (see section A.1) are 
listed with page locations in the Index by Departmental Use 
(fig. A- 8) . 

A. 5 Cross Beference Report 

One page of the Cross Beference report for elementary 
items is presented in figure A- 9 as an example. Similar 
reports are produced for group items, records, files, data 
bases, and programs with entries listed alphabetically 
within those categories. 

The element ESTIMATED-FEE can be used to illustrate the 
report, which shows that the element is defined on page 26 
of the Catalogue report. All group items, records, files, 
and programs which are recorded as using this element are 
listed, along with their page locations. Note that the data 
is repetitious. For example, for the element ESTIMATED-FEE, 
Program P3860 is listed four times. Whether this repetition 
is a program bug or intentional, it is useless and 


A- 15 



A-16 


DAT A C A T A J Q_G J E R FPHR T flATf- 02/27 /74 


SECTION 1, ELEMENTARY ITEMS 

I T 

£ M NAME 

CROSS REFER 

REVISION NUMBER- 11 

E N C_E DATELAST REVISION- P2/1S/7S 




C A T A L D 

g'uE REfEREN 

CES AND PAGE 

NUMBERS 


ELEMENTARY ITEMS 
CATALOGUE NAME 

DEFINED 
ON PAGE 

SEC HON 

CAT ALOGJ E NAME 

PAGE CATALOGUE NAME 

PAGE CATALOGUE NAME 

PAGE 

estimated-cost 

■■ 

GROUP 

MAST E R-CQLJ HN-37 — 130 

79 MAST Eft-COL UMN- 39- 1 30 

81 MASTER-COLUMN-37-138 

-. 79 . 



SEGMENT 

H AS T E R-CQ L 7 MN-39 - 1 3 8 
MASTER-RECORD 

01 

97 TRANSACTION-RECORD 

1 02 WORK I NG-STORAGE-RCD 

107 

. 


FILE 

MASTER-FILE 

118 TR AN SACT IDM-F ILE 

118 




PROGRAMS 

P3860 P38B0 

P3860 P 38 SO 

P3860 PS 8 70 





P305O P3860 


- 


£ST IMATED-FEE 

27 

GROUP 

MAST ER— COLUMN— 39-138 
MAST ER-COLJMN-37— 130 

01 M ASTER-CDL UMN- 37-138 
79 

79 MASTER— COLUMN-39— 138 

81 



SEGMENT 

MASTER-RECORD 

97 TRANSACTION-RECORD 

102 NORKLNG— STOMAS E-RCD 

107 



FILE 

MASTER-FILE 

TRANSACTION-FILE 

118 TRANSACTION-FILE 
118 

118 MASTER-FILE 

Ul 



PROGRAMS 

P3063 P388U 

P386D P30_5_a___ 

P 3860 P 3080 

P3BTQ 

P3860 P3B50 


EXTENT-QF-CJMPETITIO 

20 

SEGMENT 

MASTER-RECORD 

97 TRANSACT ION-RECORD 

102 




FILE 

MASTER-FILE 

_ _I18_ TRANSACT ION-F ILE 

__JJ.fi 




PROGRAMS 

P3B30 





FILE— SOURCE -CODE 

29 

GROUP 

HASTE R-S EDO ENCE 

82 





SEGMENT 

MASTER- RECORD 
PURGE-RECORD 

97 PURGE-RECORD 
iOl MASTER-RECORD 

101 MASTER-RECORD 
97 PUR J E-RECORD 

97 

101 



FILE 

TRANS ACT I ON-KECORD 
MASTER-FILE 

102 WORK ING- STORA GE-RCD 
110 TRAN SALT ION-F ILE 

107 

116 




PROGRAMS 

P3863 P38&0 

P 3860 P 3800 

P3860 P3B30 




- 

P3860 P360O 

P 3860 P 3850 

P3860 


FUND-SOURCE 

29 

GROUP 

MA-PY-FS 

34 MASTER— SEQUENCE 

82 MA-PV-FS 

84 



SEGMENT 

Gtl-I FMS 

Fll-IFMS 

92 F21-IFNS 
91 G22-IFNS 

91 H12-LFMS 
94 H13-1.FM$ 

95 
' 9& 




G13-I FMS 

_M AS-T-ERr RECORD 

93 HU-IFMS 
97 . PUR GEr RECORD . 

95 G23-IFMS 

101 TRANSACTION-RECORD 

94 

102 




WORK I NG-$T U RAGE-RCD 
05 003 0-1 FMS 

107 050016-IFMS 
114 G5Q005- I FM S 

1L2 050010-1 FMS 

110 WORKING-STORASE-RCD 

111 

107 




ELtHESISRY JT£MA___ mOSS REFERENCE PAGE 

— 3 


, — Example of Cross-Reference Report, Elementary Items. 


Figure A- 9 





unnecessary. The FUND-SOURCE entry shows several references 
to IFtiS transaction and report entries. 

A. 6 Other Reports 

A Structure report and a Program Revision report are 
also produced by the Data Catalogue system. The Structure 
report presents the same information as the Catalogue 
report, except that it is sequenced top-down so that all 
data related to a specified program or file can be 
considered as a single collection of data. Source portions 
of the catalogue entries may be omitted if the user so 
designates. 

The Program Revision report is intended to specify 
those programs which would require change (and the type of 
change required), if changes were in the data it uses. The 
excessively repetitious items in the reports produced to 
date are illustrated in figure A- 10. 
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DAT 

A CATALOG 

U E 




REPORT DATE- 
REVISION NUMBER— 

03/01/75 

12 




PROGRAM 

REVISION 

REP 

0 

R 

T 

DATE 

TYPE 

LAST REVISION- 
OF UPDATE- 

03/01/75 

PERMANENT 

TRANSACTION I DENT I f ICAT ION 


AFFECTED SEGMENT 

- REVISION REASON 








SECTION 

CATALOGUE NAME 

LINE 

CATALOGUE NAME 

REASON 

PRO 

G 

R 

AMS TO 

0 E 

REVISED 


I 

AS-OF-MONTH 

1001 

MASTER-RECORD 

MAX LENGTH 
FORMAT 

P3S60 



P3870 




, 




DYN OR STA 
PICTURE 








. JUST/SYNC 

1 

AS-OF-MONTH 

1002 

MASTER— RECORD 

USAGE CODE 
USAGE NAME 

P3Q60 



P3870 




OPTION 

CYCLE 
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Figure A-10. — Example of Program Revision Report. 




